In a traditional client-server authentication procedure, the client accesses a protected resource on the server by authenticating with the server using credentials of the resource owner. In order to provide third party applications with access to protected resource, the resource owner shares its credentials with the third party.
There are several drawbacks with such an authentication procedure. Third party applications have to store the credentials for future use. Servers are required to support password authentication. Third-party applications gain a broad access to the owner's protected resources. In addition, resource owner cannot revoke access to an individual third-party without revoking access to all third-parties.
The standardized OAuth (Open Authorization) Protocol introduces an authorization layer and separates the role of the client from the resource owner. In OAuth the client requests access to resources that are controlled by the resource owner and hosted by a resource server, and is issued a different set of credentials than those of the resource owner. Instead of using the credentials of the resource owner, the client obtains an access token that is a string that denotes a specific scope, duration etcetera. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client may then use the access token to access the protected resource that is hosted by the resource server.
For instance, a web user who is the owner of a resource can grant a copying service, acting as a client, access to the web user's protected photos that are stored in a photo sharing service, which service acts as a resource server. This is done without sharing the web user's username and password with the copying service. Instead, the web user authenticates herself directly with a server that is trusted by the photo sharing server, acting as an authorization server, which issues specific credentials to the copying service.
The OAuth 2.0 Authorization Protocol (draft revision 13) has almost become a de-facto standard for an authorization delegation protocol for Internet services. OAuth has the two different main flows, of which one is the authorization code flow and the other is the implicit grant flow.
In order to provide authentication of a user of a portable communication device, Generic Bootstrapping Architecture (GBA) may be combined with OAuth. User authentication is possible if the user owns a valid identity on a Home Location Register (HLR) or a Home Subscriber Server (HSS). GBA is standardized at 3rd Generation Partnership Project. Authentication of the user is enabled by sharing a secret, with one copy in the portable communication device and one copy in the HLR/HSS.
By challenging the portable communication device from the network and by verifying that the answer is same or similar to the one predicted by the HLR/HSS, the GBA authenticates the user.
The GBA establishes a shared secret between the portable communication device and a GBA Network Application Function (NAF). First, the portable communication device bootstraps a master shared secret with the Bootstrapping Server Function (BSF). After bootstrapping the master secret, the portable communication device may generate a shared secret based on the master shared secret for the GBA NAF. The service provider may retrieve the same shared key with the portable communication device from the BSF. This shared secret is limited in time and is valid for a specific domain only.
The Generic Bootstrapping Architecture (GBA) thus enables establishment of a KsNAF key between the GBA client and the GBA NAF. Thereafter the GBA NAF may retrieve the KsNAF key from the BSF, which may be used in protocols between the client and services.
An overview of a straightforward prior-art combination of OAuth and GBA for the authorization code flow and of the implicit grant flow according to the prior art is illustrated in FIG. 1 and FIG. 2, respectively.
A brief of each flow is given below.
FIG. 1 presents a co-located user agent and GBA client 102, an OAuth client being a web site 104, an authorization server 106, an authorization endpoint 108, a token endpoint 110 and a resource server 112.
The user of the user agent 102 connects (1) to the web site 104 and requests access to resources on a resource server 112. The user is then redirected (2) to an authorization endpoint 108 of the authorization server 106. The user then authorizes (3) the request for access to resources on the resource server 112. The user also authenticates (3) the request via GBA. Based on user authorization the authorization server 110 creates an authorization code and sends (4) it to the web site 104. The web site requests (5) an access token by presenting the authorization code, and received an access token. The access token may then be used to access the resource on the resource server 112 by sending (6) the access token to said resource server 112.
FIG. 2 presents a scenario for which the user agent is co-located with the OAuth client. The user of a user agent 202 requests (1) resources from a resource server 210. The web site redirects (2) the user to an authorization endpoint 206 of an authorization server 208. The user then authorizes and authenticates (3), after which the authorization server issues an access token and provides (4) a access token carried by a Uniform Resource Location (URL) fragment to the user agent 202. The web site then sends (5) a script by which the access token can be obtained from the URL fragment. The resources may then be accessed by providing the token to the resource server 210.
OAuth interworking with GBA implicates that GBA NAF is co-located on the authorization server. The user is authenticated to the Network Application Function (NAF) on the authorization server through a GBA Ua interface.
Attention is now drawn to the authorization endpoint and the token endpoint of which both are provided by the OAuth authorization server for authorization code flow, and of which the token endpoint is provided by an OAuth authorization server for implicit grant flow.
In short the authorization endpoint is used to obtain authorization from the resource owner via user-agent redirection. As a result of successful authorization, the authorization endpoint returns an authorization code to the client in the case of the authorization code flow or an access token to the client in the case of the implicit grant flow.
The token endpoint however is used to issue an access token in exchange of an authorization code after successful authentication of the client with a registered client identity and a client secret.
As illustrated in FIGS. 1 and 2, the user agent typically comprised in a portable communication device requires a number of interactions with network components. This is time consuming and consumes battery power, which always is an article in short supply. There is hence a need for an improvement of the authentication interworking with an authorization service.